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ABSTRACT 

The  aim  of  this  thesis  is  to  develop  a  model  for  a 
coordination  support  system  (CSS)  based  on  a  newly  synthesized 
coordination  theory  and  the  group  decision  support  system 
(GDSS)  model  proposed  by  Bui  and  Jarke  (1986)  .  Current 
coordination  theory  is  reviewed  and  drawn  upon  to  develop  a 
new  approach  to  coordination  which  is  then  applied  to  reach  a 
generic  CSS  design  by  establishing  modifications  to  the  GDSS 
model  module  by  module. 
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I .   INTRODUCTION 

A.  RESEARCH  OBJECTIVES 

The  aim  of  this  thesis  is  to  develop  a  model  for  a 
coordination  support  system  (CSS)  based  on  a  newly  synthesized 
coordination  theory  and  the  group  decision  support  system 
(GDSS)  model  proposed  by  Bui  and  Jarke  (Bui  and  Jarke,  1986)  . 
Current  coordination  theory  is  reviewed  and  drawn  upon  to 
develop  a  new  approach  to  coordination  which  is  then  applied 
to  reach  a  generic  CSS  design  by  establishing  modifications  to 
the  GDSS  model  module  by  module. 

Additionally,  the  purpose  of  CSS,  the  expected  benefits 
from  their  use,  a  sample  rationale  for  developing  such  a 
system  and  the  assumptions  on  which  they  are  based  are 
provided. 

B .  BACKGROUND 

For  many  years  computer  hardware  and  software  engineers 
have  worked  on  achieving  the  smoothest  and  most  efficient 
means  of  allocating  scarce  resources  such  as  main  memory,  CPU 
time  and  peripherals.  For  this  purpose,  using  various 
techniques  such  as  process  calls,  hardware  interrupts  and 
input/output  controllers  have  been  exploited.  Ideally,  the 
machine  coordinates  all  of  its  resources  via  an  operating 


system  such  that  the  user  is  presented  with  a  tool  that 
carries  out  all  of  the  instructions  provided. 

Even  in  large  distributed  computer  systems  the  user  has 
traditionally  been  provided  with  a  "virtual"  machine  that  is 
his  alone  despite  the  fact  that  there  may  be  literally 
hundreds  of  other  people  using  the  system  simultaneously.  The 
operating  system  coordinates  the  machine  resources  so  well 
that  the  user  does  not  even  realize  other  users  exist. 

All  of  this  has  been  accomplished  in  the  absence  of  a 
coherent  body  of  coordination  theory  (Malone  and  Crowston, 
1990)  .  Recent  research  in  the  fields  of  computer-supported 
collaborative  work  (Lim  and  Benbasat,  1990) ,  distributed 
artificial  intelligence  (Shaw,  et  al . ,  1990)  and 
organizational  coordination  methods  (Crowston,  1991)  indicates 
that  machines  will  not  only  be  used  to  coordinate  their  own 
activities,  but  the  activities  of  users  as  well. 

Only  recently  have  users  seen  the  potential  to  coordinate 
their  own  activities  using  a  machine  as  a  tool.  This  is 
evidenced  by  the  recent  popularity  of  office  automation  tools 
such  as  electronic  calendars,  notebooks,  spreadsheets  and  the 
like.  Several  activities  seem  to  lend  themselves  well  to 
machine  coordination.  Some  examples  are  decision  support, 
office  automation,  meeting  support  and  battle  management 
systems.  Coordination  theory  will  most  certainly  prove  vital 
to  the  further  refinement  of  existing  coordination  systems  and 
to  the  development  of  new  ones  (Malone,  1990)  . 


C .  METHODOLOGY 

In  order  to  develop  a  new  approach  to  the  design  of  a  CSS, 
a  review  of  current  work  in  the  areas  of  coordination  theory, 
coordination  methods,  command  and  control  organizations,  crew 
decision  making  and  distributed  artificial  intelligence  (DAI) 
is  conducted.  From  this  review,  a  new  coordination  theory  is 
developed  reflecting  a  systems  design  perspective. 

The  utility  of  a  CSS  is  discussed  with  respect  to  the 
expected  benefits  of  such  a  system,  particularly  in  the 
coordination  of  complex  activities.  One  activity,  the 
management  of  Anti-Aircraft  Warfare  (AAW)  assets  in  a 
hypothetical  carrier  battlegroup  (CVBG)  serves  as  an  example 
of  a  complex  coordination  activity  throughout  the  paper. 

Once  the  need  for  a  CSS  is  justified,  the  foundation  for 
building  such  a  system,  the  GDSS  model  proposed  by  Bui  and 
Jarke,  is  reviewed  to  provide  the  reader  with  a  reference  for 
the  more  detailed  discussion  to  follow. 

Finally,  modifications  to  the  GDSS  model  are  proposed  in 
order  to  form  a  generic  CSS  design. 

D.  ORGANIZATION 

Chapter  II  provides  a  definition  of  coordination  and  a 
literature  review  covering  coordination  theory  and  other 
topics  relevant  to  the  development  of  coordination  support 
systems.  A  new  coordination  theory  is  proposed  for  use  in  the 
design  of  CSS. 


Chapter  III  discusses  issues  related  to  complexity  in 
coordination  and  the  strengths  and  weaknesses  of  human  versus 
machine  coordination  of  complex  activities. 

Chapter  IV  reviews  the  GDSS  model  proposed  by  Bui  and 
Jarke  (Bui  and  Jarke,  1986)  and  describes  the  functions  of 
each  module.  This  chapter  provides  the  reader  with  a 
reference  for  the  discussion  in  the  following  chapter. 

Chapter  V  proposes  modifications  to  the  GDSS  model  that 
yield  a  model  for  a  generic  CSS. 

Chapter  VI  provides  a  summary  and  review  of  the  material 
covered,  discusses  assumptions  made  in  generating  the  generic 
CSS  model  and  poses  questions  for  further  research. 


II.   COORDINATION  AND  ITS  ELEMENTS 

A.   COORDINATION 

Before  entering  a  detailed  discussion  of  what  coordination 

is  and  what  it  is  not,  it  is  best  to  give  the  word  meaning  in 

common  terms.   Coordination,  as  defined  by  Mooney  (1947),  is 

nothing  more  than  "the  orderly  arrangement  of  group  effort,  to 

provide  unity  of  action  in  pursuit  of  a  common  purpose."   Or, 

more  simply,  the  act  of  coordination  involves  the  harmonious 

sequencing  of  events  in  order  to  achieve  a  specific  goal 

(Random  House,  1987) .   Coordination  can  be  achieved  by  an 

individual,  as  in  a  well-coordinated  athlete,  or  by  groups, 

teams,  crews  and  organizations.   A  less  formal  definition  is 

given  by  Malone  and  Crowston  (1990)  : 

We  all  have  an  intuitive  sense  of  what  the  word 
'coordination'  means.  When  we  attend  a  well  run 
conference,  when  we  watch  a  winning  basketball  team,  or 
when  we  see  a  smoothly  functioning  assembly  line  we  may 
notice  how  well  coordinated  the  actions  of  a  group  of 
people  seem  to  be.  Often,  however,  good  coordination  is 
nearly  invisible,  and  we  sometimes  notice  coordination 
most  clearly  when  it  is  lacking.  When  we  spend  hours 
waiting  on  an  airport  runway  because  the  airline  can't 
find  a  gate  for  our  plane,  when  the  hotel  room  we  thought 
had  been  reserved  for  us  is  sold  out,  or  when  a  company 
fails  repeatedly  to  capitalize  on  innovative  ideas  its 
researchers  develop  we  may  become  very  aware  of  the 
effects  of  poor  coordination. 


B.   COORDINATION  SYSTEMS 

There  are  several  types  of  computer  systems  that  assist 
users  in  coordinating  their  activities.   Some  are  designed  to 
be  used  by  a  single  user,  while  others  are  designed  for 
multiple  users.   Some  examples  follow. 
1 .   Man-Machine  Coordination 

Perhaps  the  most  obvious  instance  of  man-machine 
coordination  is  that  observed  on  modern  assembly  lines.  In 
the  case  of  automobile  manufacturing,  humans  work  side  by  side 
with  robotic  welders  and  other  machines  in  order  to  produce  a 
steady  stream  of  vehicles  to  meet  production  schedules. 

On  an  individual  level,  many  managers  now  make  use  of 
a  decision  support  system  (DSS)  to  coordinate  their  decision 
making  processes.  This  computer-based  system  is  typically 
constructed  of  a  database,  a  model  base  and  a  user  interface 
or  dialogue.  Via  the  dialogue  a  user  stores  and  retrieves 
data;  enters,  updates,  and  modifies  models;  and  manipulates 
data  using  the  available  models.  The  DSS  provides  a  pattern 
or  structure  within  which  decisions  are  made. 

The  DSS  coordinates  the  decision-making  process  by 
providing  the  user  with  the  means  to  define  a  problem  or 
decision  situation,  describe  the  environment  by  choosing  and 
tailoring  a  suitable  model,  access  the  pertinent  data  as  a 
resource  and  solve  the  problem.  Using  an  iterative  process, 
the  user  can  further  refine  the  models  and  data  to  increase 


the  accuracy  of  the  solution  or  solve  "what  if"  queries.  The 
common  "spreadsheet"  program  is  a  simple  example  of  this  type 
of  system. 

2 .   Man-Machine-Man  Coordination 

More  often,  however,  it  is  necessary  to  coordinate  the 
activities  of  a  group  of  individuals.  This  capability  falls 
in  the  arena  of  Group  Decision  Support  Systems  (GDSS)  which 
allow  groups  to  make  decisions  through  the  use  of  various 
decision  techniques  such  as  multiple-criteria  decision  methods 
(MCDM's)  and  consensus  seeking  algorithms.  In  addition  to  the 
forementioned  components  of  a  DSS,  the  GDSS  has  a 
communication  component  which  facilitates  the  involvement  of 
more  than  one  member  in  the  decision-making  process.  These 
systems  are  very  complex  and  often  have  complex  electronic 
messaging  schemes  and  sophisticated  graphical  displays.  For 
these  reasons  they  are  usually  managed  by  trained 
facilitators.  Trained  facilitators  play  a  crucial 
coordination  role  in  group  decision  making.  The  GDSS  Co-oP, 
designed  to  aid  groups  in  cooperative  multiple-criteria 
decision  making,  is  an  example  of  such  a  system  (Bui,  1987)  as 
is  the  Interactive  Management  system  (Biddle,  1991)  . 

Office  automation  systems  are  also  a  common  example  of 
coordination  systems.  They  are  designed  to  aid  in 
coordinating  the  activities  of  group  members  through  various 
communication   and   scheduling  tools   such   as   e-mail   and 


electronic  calendars.  WordPerfect  Office  is  an  example  of 
such  a  system  (Coleman,  1991)  .  Unlike  GDSS,  current  office 
automation  systems  tend  to  serve  as  media  for  solely  text- 
based  information  exchange. 

Electronic  Meeting  Systems,  such  as  that  implemented 
at  the  University  of  Arizona  (Nunamaker  et  al.,  1991),  aid 
groups  in  structuring  meetings  and  information  exchange. 

Finally,  battle  management  systems,  which  aid  military 
commanders  in  tactical  decision-making,  are  perhaps  the 
ultimate  coordination  systems.  Examples  of  existing  systems 
are  the  Naval  Tactical  Data  System  (NTDS) ,  which  chiefly  acts 
as  a  display  of  tactical  information  about  radar  and  sonar 
contacts;  and  the  Joint  Operational  Tactical  System  (JOTS) , 
which  is  a  PC-based  information  system  that  displays  and 
manipulates  information  about  contacts  worldwide  and  provides 
software  for  the  manipulation  of  various  other  data. 

C.   COORDINATION  THEORY 

There  are  a  variety  of  coordination  theories  in  the 
literature  and  it  appears  that  an  easily  distinguishable  body 
of  knowledge  about  coordination  has  not  yet  been  established 
(Malone  and  Crowston,  1990)  .  Following  are  some  of  the  more 
prevalent  theories  in  the  literature. 

Shaw  et  al.  (1990)  in  their  work  on  Distributed  Artificial 
Intelligence  (DAI)  suggest  that  coordination  is  vital  to 
multiple-agent  problem  solving.  Since  each  participant  in  the 


problem-solving  process  has  only  a  local  view  of  the  effort 
put  forth  on  the  project,  coordination  with  other  agents  is 
necessary  to  reach  solutions  efficiently.  Furthermore,  Shaw 
et  al .  review  several  mechanisms  used  to  coordinate  multiple- 
agents  in  the  problem  solving  process  including: 


Coordination  by  Revising  Actions  -  provides  a  plan  of 
group  actions  such  that  all  conflicts  among  group  members 
are  avoided. 

Coordination  by  Synchronization  -  regulates  and  controls 
the  timing  of  interactions  among  group  members  to  achieve 
solutions . 

Coordination  by  Negotiation  -  involves  two-way 
communication  to  reach  a  mutually  agreed  upon  course  of 
action . 

Coordination  by  Structured  Group  Mediation  -  involves  the 
use  of  structured  group  processes  like  the  nominal  group 
technique  and  the  brainstorming  process  to  arrive  at  a  set 
of  group  actions. 

Coordination  by  Opportunistic  Goal  Satisfaction  -  employs 
the  blackboard  model  for  problem  solving  (Nii  et  al .  , 
1989)  wherein  group  members  opportunistically  contribute 
to  the  group  solution  process. 

Coordination  by  Exchanging  Preferences  -  applies  game 
theory  to  determine  how  groups  should  interact  to  achieve 
globally  satisfactory  solutions. 


Each  of  these  mechanisms  is  described  in  detail  in  his  work. 
Orasanu  (1990)  ,  concluded  in  her  research  on  aircrew 
decision-making  that  the  use  of  certain  types  of  communication 
aided  the  development  of  shared  mental  models  (cognitive 
frameworks) ,  and  thereby  enhanced  decision-making  performance 
and  coordination. 


Research  by  Stout  et  al.  (1990)  and  Franz  et  al .  (1990) 
revealed  that  certain  behaviors  including  leadership,  decision 
making,  cooperation,  communication  and  adaptability  all  led  to 
superior  crew  coordination  and  performance. 

In  their  work  on  command  and  control  nodes  Monguillet 
(1991)  and  Levis  (1991)  model  decision-makers  using  the  Petri 
Net  Formalism  and  describe  coordination  as  the  interaction 
between  decision  making  nodes. 

Finally,  Malone  and  Crowston  (1990)  propose  a  framework 
for  analyzing  coordination  that  decomposes  the  act  of 
coordination  into  four  component  parts  and  their  associated 
processes,  see  Table  I.  "Goals"  correspond  to  the  desired 
result  of  the  coordinated  effort.  "Activities"  are  the 
individual  actions  that  must  be  completed  in  order  to  achieve 
the  desired  "goal."  "Actors"  are  the  persons  conducting  the 
"activities."  "Interdependencies"  are  the  relationships 
between  activities  which  govern  their  sequence. 

All  of  these  theories  contribute  to  the  field  of 
coordination  theory  but  none  suggest  methods  of  designing  CSS. 

D.   ELEMENTS  OF  COORDINATION 

In  this  thesis,  coordination  is  decomposed  in  order  to 
yield  elements  that  are  easier  for  the  system  designer  to 
understand  and  use  in  the  design  of  a  CSS.   To  this  end,  six 
elements  of  coordination  are  proposed  and  described  below. 
They  are  (i)  outcome,  (ii)  environment,  (iii)  resources,  (iv) 
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Table  I:  COMPONENTS  OF  COORDINATION 


Components  of  Coordination 

Associated 
Coordination  Process 

Goals 

Identifying  Goals 

Activities 

Mapping  Goals  to 
Activities 

Actors 

Selecting 
Actors /As signing 
Activities  to  Actors 

Inter dependencies 

Managing 

Inter dependencies 

time,  (v)  schedule  and  (vi)  communication.  Some  of  these 
elements  have  been  written  about  previously  by  other  authors 
but  this  set  of  six  elements  provides  the  CSS  designer  with  a 
more  designer-friendly  framework. 

An  outcome,  or  goal,  is  the  desired  result  of  the 
coordinated  event,  its  key  objective.  For  an  outfielder,  it 
may  be  catching  a  fly  ball;  for  an  F/A-18  crew,  it  may  be  a 
successful  bombing  mission  or  for  a  construction  crew,  it  may 
be  the  completion  of  a  new  building  on  schedule.  Whatever  the 
outcome,  it  must  be  identified  before  it  can  be  coordinated. 
On  a  computer  the  outcome  would  have  to  be  selected  from 
perhaps  several  outcomes  listed  on  a  menu  before  the  machine 
could  proceed  with  the  coordinating  process.  Malone  and 
Crowsten  (1990)  use  the  term  "goal"  in  place  of  outcome. 
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The  environment  must  then  be  evaluated  for  conditions  that 
may  effect  the  coordination  process.  These  conditions 
include,  but  are  not  limited  to  weather  conditions,  economic 
conditions,  political  conditions,  even  traffic  conditions.  It 
is  important  to  note  that  the  environment  can  not  be 
controlled  or  directed  by  the  coordination  process  but,  in 
contrast,  it  can  impact  the  coordination  process  in  many  ways. 
Environmental  conditions  include  any  externality  that  could 
effect  the  coordination  process.  Environmental  sensors  can  be 
linked  to  a  computer  providing  continuous  information  on 
elements  of  the  environment  important  to  the  coordination 
process.  Cheng  (1983)  supports  the  importance  of  the 
environment  in  the  coordination  process. 

Resources  are  those  elements  which  play  an  active  role  in 
achieving  the  selected  outcome.  In  the  previous  examples  they 
may  be  the  number  of  outfielders,  the  number  of  bombs  or  the 
number  of  bulldozers  and  cranes.  There  are  often  many 
resources  that  must  be  considered  in  complex  coordination 
processes,  e.g.  in  landing  a  plane.  Before  landing,  a  myriad 
of  resources  must  be  checked  such  as  the  electro-hydraulic 
system,  landing  gear,  flaps,  rudders,  tire  rotation, 
availability  of  a  runway  etc.  Without  any  one  of  these  the 
successful  achievement  of  the  desired  outcome  may  be  severely 
impaired.  Resources  can  also  be  linked  to,  or  make  use  of,  a 
computer   to   receive   information   and   provide   feedback. 
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Resources  correspond  to  "actors"  in  the  Malone  and  Crowsten 
(1990)  framework. 

Time  is  the  fourth  key  element  in  the  coordination 
process.  The  selected  outcome  must  be  assigned  a  time  for 
completion  or  maximum  duration,  i.e.  the  outcome  must  have  a 
due  date  or  deadline.  It  may  be  determined  that  there  is  not 
enough  time  to  achieve  a  particular  outcome  without 
sacrificing  some  intermediate  steps,  perhaps  safety  checks,  or 
overriding  default  limits.  If  this  is  the  case,  a  decision 
must  be  made  to  either  cease  or  continue  the  coordination 
process.  In  some  cases  the  deadline  will  be  "as  soon  as 
possible"  but  this  must  be  known  for  the  coordination  process 
to  continue  to  the  next  step.  Computers  monitor  the  passage 
of  time  using  internal  clocks  and  can  be  programmed  to 
generate  alerts  when  certain  time  constraints  are  not  met. 

Once  the  outcome  is  determined,  the  environment  and 
resources  checked  and  a  deadline  assigned,  a  schedule  can  be 
generated  that  will  guide  the  individual  or  group  members 
toward  the  completion  of  the  coordination  process.  In  the 
case  of  a  group  or  crew  coordinated  event,  the  schedule  will 
have  role  specific  task  assignments  for  each  person  (resource) 
and  make  provisions  for  assignments  to  be  carried  out  in 
parallel  where  possible  or  necessary.  Schedule  generation 
involves  managing  the  "interdependencies"  of  Malone  and 
Crowston  (1990)  . 
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Finally,  communication  of  the  schedule,  and  feedback  on 
the  progress  of  the  participants  through  the  schedule,  is 
required  to  effectively  implement  the  coordination  process. 
Aircrews  commonly  use  checklists  to  help  them  through  the 
coordination  process.  One  member  reads  the  checklist  while 
the  others  verify  that  certain  conditions  exist  then  respond 
with  verbal  confirmations  of  compliance.  Computers  can 
communicate  via  network  linkages  with  other  computers  and  data 
sources  (Fitzgerald,  1990).  Without  communication,  the 
coordination  process  could  not  take  place,  in  fact,  some 
consider  communication  to  be  the  key  to  coordination  (Stoner 
and  Freeman,  1989) . 

All  of  these  six  elements  must  be  considered  and  built 
into  the  design  of  a  coordination  support  system  to  make  it 
effective . 

E.   THE  ROLE  OF  COMMUNICATION  IN  GROUP  COORDINATION  EFFORTS 

The  importance  of  smooth  communication  in  the  coordination 
process  cannot  be  overstated,  it  is  fundamental  to  group  work 
(Lim  and  Benbasat, 1990) .  Often  environmental  conditions  and 
resources  can  be  overlooked  and  time  and  schedule  requirements 
can  be  adjusted  but,  without  communication,  the  entire  process 
will  become  ineffective. 

1 .   Communication  Dimensions 

Group  communication  situations  can  be  classified 
according  to  four  different  dimensions  (Jarke,  1986) :   (i) 
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spatial  distance,  (ii)  temporal  distance,  (iii)  centralization 
of  control  and  (iv)  degree  of  cooperation. 

Spatial  distance  refers  to  the  actual  distance  between 
group  members.  Are  they  meeting  in  the  same  room  or  are  they 
widely  distributed  and  communicating  via  telephone,  radio, 
computer,  or  videoconference? 

Temporal  distance  refers  to  the  time  between  inputs  to 
the  communication  process.  Are  group  members  communicating 
one  immediately  after  the  other  or  are  their  inputs  separated 
by  days,  weeks  or  months? 

Centralization  of  control  refers  to  the  level  of 
equality  of  the  group  members.  Does  one  member  have  more 
power  than  the  others  or  are  all  of  their  communications 
considered  of  equal  importance? 

Degree  of  cooperation  refers  to  the  communication 
style  of  the  group.  Are  they  striving  to  achieve  a  common 
goal  or  are  they  negotiating  or  debating  a  point? 

These  four  dimensions  must  be  considered  by  a  CSS 
designer  if  his  system  is  to  be  successful.  For  example,  a 
CSS  in  which  the  resources  are  widely  separated  (spatial 
distance)  must  provide  a  means  of  communicating  between  the 
various  remote  locations.  Also,  if  the  CSS  is  to  support 
asynchronous  input  by  resources  (temporal  distance) ,  the 
designer  must  implement  the  additional  communication 
capabilities . 
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2 .   Time-Space  Taxonomy 
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Figure  1  A  Taxonomy  of  Groupware  (Ellis  et  al . ,  1991) 

Ellis  et  al.  (1991)  provide  a  diagrammatic  taxonomy 
(Figure  1)  expressing  the  differences  between  various  types  of 
"groupware"  (software  designed  for  use  in  group  systems) .  The 
simple  two-by-two  matrix  distinguishes  between  distributed  and 
local  group  systems  on  one  axis  and  between  real-time  and 
asynchronous  group  systems  on  the  other.  In  the  upper  left 
quadrant,  one  would  find  an  Anti-Aircraft  Warfare  CSS,  in  the 
lower  left,  a  nuclear  power  plant  CSS,  in  the  upper  right,  a 
nationwide  telecommunications  trouble  shooting  CSS  and  in  the 
lower  right,  a  project  management  CSS.   Each  type  of  system 
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has  its  own  communication  requirements  and  a  comprehensive  CSS 
should  be  capable  of  exploiting  them  all. 
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III.    INHERENT  COMPLEXITY  IN  COORDINATION:  THE  CASE  OF 
COORDINATING  ANTI-AIRCRAFT  WARFARE 


A.   BACKGROUND 

1 .   A  Brief  Description  of  Anti-Aircraft  Warfare 

Anti-Aircraft  Warfare  (AAW)  is  a  highly  complex 
activity  requiring  sophisticated  command,  control  and 
communication  systems  and  the  precise  coordination  of  many 
widely  dispersed  participants.  A  simplified  AAW  scenario 
involving  only  the  use  of  fighters  and  other  tactical  air 
assets  will  serve  to  illustrate  the  level  of  complexity 
frequently  encountered  in  similar  situations. 

In  order  to  provide  the  carrier  battle  group  (CVBG) 
with  an  appropriate  defense  against  hostile  aircraft  and  anti- 
ship  missiles,  the  Anti-Aircraft  Warfare  Commander  (AAWC)  must 
be  able  to  detect,  intercept  and  destroy  enemy  aircraft 
capable  of  firing  missiles  (missile  platforms) .  In  the  case 
of  some  of  the  most  threatening  air-launched  anti-ship  cruise 
missiles  this  translates  into  a  requirement  that  the  AAWC  have 
control  of  fighter  aircraft  resources  with  which  to  create  a 
barrier  capable  of  destroying  airborne  enemy  cruise  missile 
platforms  before  they  launch  their  weapons. 

Though  the  AAWC  is  not  normally  located  aboard  the 
aircraft  carrier,  he  has  the  authority  to  direct  the  launch  of 
alert  aircraft  in  order  to  fulfill  his  requirements.   Upon 
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doing  so,  the  AAWC  becomes  responsible  for  the  aircraft  until 
it  is  safely  back  on  deck.  This  includes  keeping  aware  of 
vital  systems  status,  weapons  loadout,  pilot  condition  and 
fuel  status.  The  AAWC  instructs  the  pilot  on  the  direction 
and  speed  to  the  intercept  point,  the  point  at  which  the 
fighter  could  conceivably  launch  missiles  to  intercept  the 
incoming  hostile  missile  platform,  what  to  do  when  he  arrives 
at  the  intercept  point,  how  long  to  stay  there  and  when  to 
return.  Should  a  fighter  fail  to  reach  the  intercept  on  time, 
the  hostile  aircraft  could  launch  its  cruise  missiles 
unmolested  and  the  liklihood  of  severe  damage  to  the  CVBG 
would  increase  greatly.  It  is  this  consequence  that  the  AAWC 
must  strive  to  prevent. 

Based  on  the  perceived  threat  at  any  given  time  the 
CVBG  adopts  a  specific  readiness  posture.  The  AAWC  designates 
the  number  of  aircraft  of  each  type  (fighters,  tankers, 
airborne  early  warning  (AEW)  aircraft)  to  have  in  various 
alert  states  based  on  the  current  readiness  posture. 

Accurate  environmental  inputs  are  critical  to  success. 
Among  these  are  wind  speed  and  direction,  atmospheric 
conditions,  cloud  conditions,  visibility,  humidity,  rain, 
snow,  proximity  to  land,  the  current  Rules  of  Engagement 
(ROE),  precise  position  of  the  CVBG  etc.  Often  these  factors 
determine  the  ability  to  launch  and  land  aircraft,  sensor 
performance,  aircraft  engine  performance,  the  ability  to 
engage  a  target  etc.   Ignorance  of  these  inputs  may  cause  the 
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AAWC  to  needlessly  endanger  the  safety  of  an  aircrew  or  even 
the  CVBG  or  cause  an  adverse  political  incident. 

Initially,  the  AAWC  is  concerned  with  detecting  enemy 
aircraft  at  a  distance  great  enough  to  allow  time  for  him  to 
respond.  He  has  various  assets  (resources)  at  his  disposal  to 
do  this  including  but  not  limited  to  intelligence,  long  range 
air  search  radar,  and  AEW  systems.  Once  an  enemy  is  detected 
and  classified,  the  time  to  weapons  release  must  be 
calculated.  This  time  is  based  on  the  position  of  the  enemy 
relative  to  the  CVBG,  the  classification  and  probable  loadout 
of  the  enemy,  the  enemy  course  and  speed,  and  the  CVBG  course 
and  speed. 

Next,  the  AAWC  must  determine  the  appropriate  aircraft 
to  conduct  the  intercept.  Indeed,  there  may  already  be  an 
aircraft  airborne  that  could  do  the  job.  Consideration  must 
be  given  to  pilot  fatigue,  fuel  status,  equipment  status  etc. 
If  the  decision  is  to  conduct  the  intercept  with  an  aircraft 
that  was  returning  to  the  carrier,  it  may  be  necessary  to 
launch  a  tanker  to  provide  in-flight  refueling  services  to  the 
returning  aircraft  before  sending  it  out  again.  If  the 
intercept  must  be  made  quickly  due  to  a  late  detection,  the 
increased  fuel  burn  rate  of  the  interceptor  racing  to  the 
intercept  must  trigger  the  launch  of  a  tanker  as  well.  Timing 
is  critical  since  battlegroup  survival  may  be  at  stake. 

Data  regarding  the  weapons  loadouts,  cruise  speeds, 
attack  speeds,  dash  speeds,  ranges,  sensors,  tactics  etc.  of 
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all  enemy  aircraft  must  be  easily  accessible.  Likewise, 
corroborating  historical  data  should  also  be  accessible. 
Similar  data  about  all  friendly  aircraft  must  also  be 
maintained  including  alert  status,  engagement  status,  and 
launch  delay  status. 

During  periods  of  sustained  high  threat  the  AAWC 
promulgates  a  schedule  that  directs  the  employment  of  aircraft 
toward  the  end  of  CVBG  defense.  The  schedule  provides  for 
regular  launch  and  recovery  of  aircraft,  their  assigned 
stations,  fuel  requirements,  and  action  to  be  taken  if  an 
enemy  aircraft  is  detected. 

Communication  channels  between  the  AAWC  and  all 
airborne  friendly  aircraft  must  be  maintained  in  addition  to 
the  channel  between  the  Battle  Group  Commander  and  the  AAWC  so 
that  vital  information  can  be  shared.  Often  this  is  done 
using  encrypted  signals. 

2.   Anti-Aircraft  Warfare  and  the  Elements  of  Coordination 

A  rapidly  changing  environment  can  cause  the 
coordination  process  to  become  complex  by  forcing  the 
coordinator  to  reevaluate  earlier  choices  and  determine  if 
they  remain  valid.  It  may  also  impede  the  initial  decision  to 
take  action  at  all.  For  example,  consider  the  AAWC's  choice 
of  the  number  of  aircraft  to  have  in  a  particular  alert 
status.  Should  the  political  environment  change,  the 
corresponding  threat  readiness  level  of  the  entire  CVBG  may 
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change  necessitating  a  change  in  the  AAWC's  alert 
requirements . 

Having  a  large  number  of  resources  to  monitor  can  also 
have  a  dramatic  effect  on  the  complexity  of  coordination. 
Monitoring  a  diversity  of  resources  is  a  time  consuming  and 
confusing  problem  often  involving  parallel  processing.  For 
example,  it  is  not  uncommon  for  the  AAWC  to  be  monitoring 
three  communication  channels  (AAWC-CVBG  Commander /AAWC- 
Aircraft/  AAWC-AAW  Capable  Surface  Ships) ,  four  displays 
(NTDS/Status  Boards/Navigational  Charts/Air  Charts)  and  the 
status  of  dozens  of  aircraft.  The  volume  of  information 
flowing  to  one  person  often  can  not  be  assimilated  quickly 
enough  which  results  in  information  loss. 

When  events  need  to  be  coordinated  on  a  real-time 
basis  rather  than  over  a  long  time  span,  the  coordination 
process  is  more  complex.  This  is  due  to  a  distinct  lack  of 
time  to  follow  the  decision  processes  necessary  to  make  or 
modify  schedules .  Often  the  achievement  of  a  particular 
outcome  is  desired  in  a  relatively  short  time  span,  as  in  the 
proper  handling  of  a  surprise  missile  attack.  There  is  little 
time  during  an  emergency  to  coordinate  group  actions,  think 
about  what  must  be  done  and  issue  instructions.  To  improve 
coordination,  pre-planned  responses  to  particular  situations 
are  developed  and  practiced  regularly  so  that  they  may  be 
performed  swiftly  and  safely  when  required. 


22 


As  the  interdependence  of  events  increases,  so  does 
the  complexity  of  the  coordination  process  (Cheng,  1983) .  The 
communication  overhead  required  to  monitor  interdependences 
often  slows  the  coordination  process  and  the  generation  of 
schedules .  For  example,  the  choice  of  an  aircraft  to  conduct 
an  intercept  is  dependent  on  the  type  of  enemy  aircraft,  its 
loadout,  speed  and  range,  the  time  to  weapons  release 
distance,  the  availability  of  fighters  and  tankers,  their 
loadout,  systems  status  etc.  Highly  interdependent  events 
form  virtual  bottlenecks  in  the  coordination  process,  see 
Figure  2.  See  Malone  and  Crowston  (1990)  or  Crowston  (1991) 
for  a  treatment  of  the  types  of  interdependence. 


Event  E,  at  left,  is  dependent  on  A.B.C 
and  D  being  completed  before  it  can  be 
started  and  therefore  must  receive  four 
times  more  communication  flow  than 
events  dependent  on  only  one  other  event 
as  in  F  at  right 


Figure  2  Interdependent  Events 
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Difficulty  in  communication  can  also  impede  the 
coordination  process  by  halting  the  flow  of  information 
between  group  or  crew  members.  When  information  flow  is 
disrupted  it  becomes  impossible  to  coordinate  interdependent 
events  and  to  monitor  resources  or  the  environment.  Without 
radio  contact,  the  AAWC  would  find  it  nearly  impossible  to 
coordinate  the  actions  of  his  many  resources  for  any 
reasonable  length  of  time.  In  practice,  he  is  confined  to  the 
use  of  pre-planned  responses. 

B.   HUMAN  FACTORS 

These  were  just  a  few  isolated  samples  of  causes  of 
increased  complexity  in  the  coordination  process.  The  reality 
is  in  fact  even  more  complex.  All  of  this  complexity  can 
cause  a  coordinator  to  become  overwhelmed  which  ultimately 
leads  to  failure  to  achieve  the  desired  outcome. 

Typically  decision-makers  become  overwhelmed  when  they  are 
unable  to  assimilate  information  at  a  high  enough  rate  or  they 
do  not  know  what  to  do  with  the  information  they  have.  In 
essence,  they  become  input/output  (I/O)  bound  and  are  unable 
to  process  the  information  they  are  receiving.  When  this 
happens,  decisions  are  made  on  a  primarily  subjective  "gut 
feeling"  basis  and  therefore  can  be  partially  or  wholly 
illogical . 
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Humans  can  also  be  tired,  bored,  anxious,  impatient, 
angry,  ill  etc.  and  their  performance  is  often  affected  by 
their  current  disposition. 

Battle  management  in  a  multi-threat  environment  is  often 
an  overwhelming  situation.  A  ship  tasked  with  defending 
itself  against  hostile  surface,  air  and  submarine  attacks 
simultaneously  must  collect,  evaluate  and  make  decisions  based 
on  an  enormous  amount  of  information;  all  on  a  real-time 
basis.  The  entire  process  is  often  described  as  "managed 
chaos"  and  requires  a  well-practiced  team  to  prevent  a 
disastrous  failure  in  the  defense. 

C.   EXPECTED  BENEFITS  OF  COORDINATION  SUPPORT  SYSTEMS 

Given  that  events  can  become  extremely  difficult  to 
coordinate  and  the  fact  that  they  often  must  be  coordinated 
despite  their  complexity,  avenues  of  alleviating  some  or  all 
of  the  difficulty  must  be  sought.  Since  machines  have 
capabilities  to  complement  or  augment  those  of  humans,  they 
are  a  logical  choice. 

First,  they  are  capable  of  being  programmed  with  the 
routines  to  handle  a  large  number  of  desired  outcomes.  This 
relieves  the  human  coordinator  of  the  responsibility  for 
maintaining  checklists  and  memorizing  procedures.  The 
routines  will  be  executed  smoothly  and  efficiently  without 
skipping  steps.  Additionally,  these  routines  are  infused  with 
the  knowledge  of  experts  in  the  specific  field  and  would 
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therefore  prescribe  actions  that  the  novice  may  overlook  or 
deem  unimportant . 

Second,  machines  are  capable  of  continuously  monitoring 
vast  amounts  of  incoming  data  from  environmental  sensors.  The 
machine  can  be  programmed  to  take  specific  actions  when 
certain  limits  are  triggered  by  the  incoming  data  flow. 
Machines  are  rarely  "overwhelmed"  by  excessive  data  flow  and 
therefore  are  not  as  prone  to  information  losses. 

Third,  machines  can  monitor  resources  continuously  and 
tirelessly.  A  machine  will  not  become  tired,  bored,  angry  or 
ill. 

Fourth,  a  machine  can  process  data  on  a  real  time  basis 
without  becoming  confused  by  data  flow.  Program  execution 
rates  far  outpace  the  rate  of  human  cognition  in  routine 
information  processing. 

Last,  machines  can  manage  and  provide  for  communications 
between  members  of  a  group  or  crew,  even  on  a  decentralized, 
asynchronous  basis.  NTDS  is  an  existing  example  of  this 
technology . 

Given  these  capabilities,  it  appears  that  a  coordination 
support  system  could  indeed  simplify  the  coordination  process 
by  off-loading  many  responsibilities  of  the  human  coordinator 
thus  allowing  him  to  concentrate  on  the  more  important  parts 
of  the  process.  The  remainder  of  this  thesis  proposes  a  model 
on  which  to  base  the  design  of  a  generic  CSS. 
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IV.   THE  FOUNDATION 

A.   THE  GDSS  MODEL 

Because  the  design  of  the  GDSS  is  so  flexible  and  it 
already  provides  many  of  the  functions  necessary  to  implement 
a  coordination  support  system,  the  current  GDSS  model  will 
form  the  foundation  for  our  further  study.  Sprague  and 
Carlson  (1982)  proposed  a  fundamental  DSS  architecture 
composed  of  three  main  components:  (i)  the  dialogue  manager, 
(ii)  the  data  manager  and  (iii)  the  model  manager.  Each  was 
discussed  briefly  earlier.  Bui  and  Jarke  proposed  an 
additional  fourth  component  fundamental  to  a  distributed  GDSS, 
the  communication  manager.  Each  component  will  be  examined  in 
detail  below. 

1 .   The  Dialogue  Manager 

The  dialogue  manager  provides  the  user  interface 
function  for  the  GDSS.  As  an  interface  feature,  there  are 
several  possible  styles.  Among  them  are:  (i)  command 
language,  (ii)  menu,  (iii)  formatted  form  and  (iv)  prompt 
(Awad,  1988)  .  The  dialogue  of  any  given  system  may  use  one  or 
more  of  these  styles  to  interface  with  the  user  and  allow  him 
to  make  use  of  the  database,  model  management  and 
communication  functions  of  the  GDSS. 
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2 .  The  Data  Manager 

The  data  manager  provides  the  functions  of  a  database 
and  a  database  management  system  (DBMS)  for  the  GDSS. 
According  to  Kroenke  and  Dolan  (1988) ,  a  generic  DBMS  performs 
the  following  functions:  (i)  store,  retrieve  and  update  user 
data,  (ii)  store,  retrieve  and  update  meta-data,  (iii)  enforce 
data  integrity  rules  and  constraints,  (iv)  enforce  security 
constraints,  (v)  provide  coordination  and  control  facilities 
for  multi-user  processing  and  (vi)  provide  facilities  for 
system  backup  and  recovery.  In  addition,  the  DBMS  must  be 
capable  of  handling  both  internal  and  external  data.  All  of 
these  functions  are  required  by  the  GDSS  and  the  user  can 
invoke,  setup  or  make  use  of  them  through  the  dialogue. 

3 .  The  Model  Manager 

The  model  manager  gives  the  user  the  ability  to 
explore  a  problem  completely  by  developing  and  comparing 
alternative  solutions  (Sprague  and  Carlson,  1982)  .  There  is 
a  model  base,  which  is  composed  of  a  set  of  analytical  models, 
equations  and  algorithms  and  a  modelbase  management  system 
(MBMS)  which  provides  DBMS-like  functions  for  the  model  base. 
Four  basic  functions  of  the  MBMS  include:  (i)  generation  of 
models,  (ii)  restructure  of  models,  (iii)  update  of  models  and 
(iv)  report  generation  and  inquiry  (Sprague  and  Carlson, 
1982)  .   The  models  have  access  to  data  in  the  database  via  the 
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DBMS  and  can  generate  solutions  to  inquiries  posed  on  a 
regular  or  ad  hoc  basis. 

4 .   The  Communication  Manager 

Finally,  the  communication  manager  proposed  by  Bui  and 
Jarke  is  composed  of  four  main  parts:  (i)  the  group  norm 
constructor,  (ii)  the  group  norm  filter,  (iii)  the  invocation 
mechanism  and  (iv)  the  IDSS-GDSS  information  formatter. 

a.  The   Group  Norm  Constructor 

The  group  norm  constructor  is  used  to  define  group 
members,  communication  channels  and  group  decision  rules. 
This  is  achieved  through  a  group  leader  or  facilitator 
collecting  information  according  to  a  checklist.  User 
identification,  communication  methods  and  decision  models  are 
specified  explicitly  so  that  all  users  and  the  system  have  a 
common  reference. 

b.  The   Group  Norm  Filter 

Once  this  information  is  entered  into  the  group 
norm  constructor,  it  is  compiled  into  a  set  of  instructions 
called  the  group  norm  filter.  The  purpose  of  the  group  norm 
filter  is  to  enforce  the  protocol  defined  using  the 
constructor.  Specifically  the  group  norm  filter  performs 
three  functions:  (i)  grants  access  to  users  based  on 
identification  and  password  and  warns  users  of  upcoming 
decision  deadlines,  (ii)  monitors  all  user  data  transfers, 
ensuring  they  are  in  accordance  with  the  established  protocol 
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and  (iii)  monitors  the  computation  of  the  group  decision 
results  by  the  model  manager.  Via  these  functions,  the  group 
norm  filter  ensures  the  decision  process  proceeds  as  defined. 

c.  The  Invocation  Mechanism 

In  order  to  provide  a  degree  of  flexibility  to  the 
functions  of  the  communication  manager,  the  invocation 
mechanism  was  designed  to  enable  the  group  to  request  and  make 
modifications  to  the  protocol  defined  using  the  group  norm 
constructor.  In  this  manner  the  protocol  can  be  partially 
redefined  during  the  decision  process;  to  add  another  group 
member  for  instance.  Since  members  must  approve  changes 
before  they  are  made,  the  invocation  mechanism  also  provides 
a  means  of  notifying  and  convening  members  to  make  such  a 
decision . 

d.  The   IDSS-GDSS  Formatter 

Finally,  the  IDSS-GDSS  formatter  enables  the  GDSS 
to  communicate  with  other  IDSS  in  a  distributed  system  by 
supplying  the  appropriate  data  conversion  protocols.  Without 
this  ability,  a  distributed  GDSS  would  not  be  possible. 

B.   A  COMPARISON 

To  alleviate  some  of  the  confusion  caused  by  the  varied 
terminology  used  in  discussing  coordination  theory  and 
systems,  Table  II  provides  a  simple  comparison. 
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Table  II  COMPARISON  OF  TERMS 


MALONE/ CROWS TON 

CSS 

GDSS 

GOALS 

OUTCOMES 

GROUP  NORM 
CONSTRUCTOR 

ENVIRONMENT 

ACTORS 

RESOURCES 

GROUP  NORM 
CONSTRUCTOR 

TIME 

GROUP  NORM 
CONSTRUCTOR 

ACTIVITIES/ 
INTERDEPENDENCES 

SCHEDULE 

GROUP  NORM 
FILTER/ 
INVOCATION 
MECHANISM 

COMMUNICATION 

GROUP  NORM 
CONSTRUCTOR/ 
INFORMATION 
FORMATTER 

C.   SUMMARY 

Having  outlined  the  component  structure  of  a  generic  GDSS 
and  discussed  the  functions  of  each  part,  it  is  easy  to  see 
how  the  generic  GDSS  will  provide  a  suitable  foundation  for  a 
coordination  support  system.  In  order  to  construct  a  generic 
CSS,  however,  some  modifications  must  be  made  to  each  of  the 
components  .   These  are  the  subject  of  the  next  chapter. 
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V.   MODIFICATIONS  TO  THE  MODEL 

A.   THE  NATURE  OF  A  COORDINATION  SUPPORT  SYSTEM 

Before  delving  into  the  design  specifics  of  a  CSS,  a 
discussion  of  how  a  CSS  would  be  used  might  greatly  assist  the 
reader  in  understanding  the  design  rationale  proposed  in  later 
sections  of  this  chapter. 

1 .  Selection  Phase 

Faced  with  the  responsibility  for  coordinating  a 
particular  activity,  the  user  would  begin  his  interaction  with 
the  CSS  by  selecting  from  a  menu  or  outcome  library  the 
particular  outcome  that  corresponds  to  the  activity  he  wishes 
to  coordinate,  e.g.  intercept  a  hostile  aircraft  etc.  Each 
CSS  would  have  a  domain  similar  to  that  found  in  expert 
systems  (Sol,  1987)  .  The  domain  is  the  description  of  the  set 
of  outcomes  the  CSS  is  designed  to  handle.  This  initial  phase 
is  known  as  the  selection  phase.  Here  the  user  selects  an 
outcome  which  in  turn  invokes  a  specific  program  branch  that 
deals  with  the  outcome  the  user  specifies. 

2 .  Resource  Allocation  Phase 

Once  an  outcome  is  selected,  an  activity  specific 
program  is  invoked.  The  user  will  then  be  prompted  to  give 
the  system  necessary  information  about  resources, 
environmental   inputs,   time  constraints  and  communication 
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channels.  The  user  must  define  such  items  as  the  number  of 
human  resources  and  their  roles,  non-human  resources, 
environmental  inputs,  the  deadline  for  completion  of  the 
outcome  and  the  communication  channels  for  all  resources  and 
environmental  inputs.  Depending  on  the  CSS  some  of  the 
resources,  environmental  inputs  and  communication  channels  may 
have  default  values  and  others  may  be  permanently  assigned. 
The  important  issue  is  that  the  CSS  be  able  to  communicate 
with  all  resources  and  receive  pertinent  environmental 
information.  The  entry  of  this  information  concludes  the 
resource  allocation  phase. 

3 .   Schedule  Generation  Phase 

Information  entered  during  the  resource  allocation 
phase  is  now  passed  to  the  schedule  generator  which  uses 
optimization  models,  heuristic  and  mathematical  analysis  and 
logical  algorithms  to  generate  resource  specific  and 
contextually  sensitive  schedules  for  use  in  coordinating  the 
activity  requested  by  the  user.  Generic  models  and  algorithms 
would  be  part  of  the  CSS  modelbase  whereas  activity  specific 
models  would  be  a  component  of  the  activity  specific  program. 
Each  schedule  would  be  resource  specific  and  composed 
of  schedule  elements,  or  tasks,  to  be  completed  by  a  specific 
deadline.  Only  those  items  that  the  machine  is  not  capable  of 
doing  would  be  part  of  the  schedule.    Warnings  would  be 


33 


generated  whenever  insufficient  time  precluded  completion  of 
the  coordination  process. 

4 .  Output  Generation  Phase 

The  CSS  would  now  take  the  output  from  the  schedule 
generation  phase  and  communicate  it  to  the  resources 
previously  defined.  These  outputs  may  take  the  form  of 
electro-mechanical  instructions  to  devices  capable  of  digital 
control,  messages  sent  via  network  or  modem  to  remote  human 
resources,  printed  instruction  sheets,  screen  instructions, 
alerts  or  even  synthetic  voice  commands.  The  output  is  the 
link  by  which  the  CSS  directs  the  actions  of  the  resources  in 
order  to  coordinate  the  desired  activity. 

5 .  Monitoring  Phase 

Finally,  the  CSS  would  monitor  the  assigned 
communication  channels  for  feedback  from  resources  indicating 
completion  of  schedule  elements.  The  CSS  would  also  provide 
alerts  to  the  resources  as  appropriate  indicating  impending 
deadlines  and/or  overdue  schedule  elements. 

An  additional  feature  of  the  system  would  be  a 
mechanism  to  change  elements  of  the  resource  allocation  phase 
at  any  point  in  time  so  that  new  resources  or  inputs  could  be 
added  or  old  ones  deleted. 

B.   OVERVIEW 

In  summary,  the  user  first  selects  a  desired  outcome,  to 
intercept  a  hostile  aircraft  for  instance.   He  then  defines 
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the  environmental  inputs  (wind  speed,  ship's  navigational 
inputs,  radar  etc)  and  the  communication  path  the  CSS  is  to 
make  use  of  to  receive  all  pertinent  data  (COMM  1) .  Next  he 
defines  the  various  resources  such  as  the  AAWC,  airborne 
fighters,  alert  fighters  on  deck,  tankers,  AEW  aircraft  etc 
and  the  communication  channels  assigned  to  them  (e.g.  video 
display,  NTDS,  voice  radio) .  Finally  a  desired  time  of 
intercept,  or  in  this  case  a  range  is  sometimes  more 
appropriate,  is  provided  to  the  system.  To  assist  the  user  in 
the  resource  allocation  phase,  the  system  would  provide 
default  values  and  the  capability  to  save  previous  setups. 

The  CSS  would  subsequently  generate  directions  in  the  form 
of  schedules  for  each  resource  involved  in  the  intercept 
process  based  on  previously  programmed  heuristics  and  the 
input  it  receives  on  the  communication  channels  it  monitors. 
The  system  can  even  be  programmed  to  request  data  it  needs  to 
complete  its  analysis.  Once  the  schedules  are  communicated, 
the  CSS  would  monitor  resource  communication  channels  for 
feedback  on  progress  through  the  schedule  (interceptor 
launched  to  station  One  Two  Delta  etc) . 

C.   THE  GDSS  MODEL  REVISITED 

From  the  previous  discussion,  the  reader  can  see  that  the 
GDSS  model  described  in  Chapter  IV  provides  a  logical 
foundation  for  modeling  the  proposed  CSS  since  it  already 
provides   many   of   the   required   functions.      Required 
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modifications  to  the  GDSS  model  are  the  subject  of  the 
following  sections. 

1.   The  Revised  Dialogue  Manager 

The  functions  of  the  GDSS  dialogue  manager  would  not 
differ  much  from  those  of  the  usual  GDSS  user  interface:  (i) 
provide  the  user  with  a  representation  of  the  system  and  (ii) 
provide  the  user  with  a  means  of  controlling  the  system 
(Sprague  and  Carlson,  1982) .  A  good  dialogue  is  essential  to 
the  system  for  if  it  is  unfriendly  or  obscure,  the  system  may 
be  rejected  entirely  by  the  user  (Awad,  1988)  . 

Specifically,  the  dialogue  would  need  to  enable  the 
user  to  perform  the  following  functions: 


•  Select  an  outcome  from  a  list  or  library  of  supported 
outcomes.   (Menu) 

•  Define  environmental  inputs,  resources,  time  constraints 
and  communication  channels.   (Formatted  Form) 

•  Respond  to  alerts,  error  messages  and  acknowledgements. 

(Prompt) 

•  Issue  instructions  to  the  database,  modelbase  and 
communication  managers  via  the  invocation  mechanism. 
(Command  Language) 


As  noted  parenthetically  above,  the  dialogue  style  would  be  a 
mixture  of  the  common  forms.  All  of  the  styles  are  within 
current  state-of-the-art  dialogue  design  capabilities. 

The  display  of  data,  whether  textual  or  graphical,  is 
another  function  of  the  dialogue  manager  that  must  be 
carefully  implemented  to  ensure  user   acceptance  of  the  CSS. 
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2.   The  Revised  Data  Manager 

The  data  manager  must  be  capable  of  fulfilling  all  of 
the  requirements  delineated  in  Chapter  IV.  Of  paramount 
importance  is  the  ability  to  support  multiple  environmental 
inputs  and  resources  in  a  distributed  CSS.  This  implies 
several  capabilities  including: 

•  Send  and  receive  data  to  and  from  multiple  resources 

•  Receive  data  from  environmental  inputs 

•  Encrypt/decrypt  data  for  security 

•  Store,  retrieve  and  update  internal  data 

•  Manage  data  buffers  and  queues 

•  Interface  with  dialogue  manager  for  the  display  of  data 

•  Store  default  values  and  communication  setups 

•  Store  transaction  reports  for  post-action  analysis 

As  can  be  seen,  the  data  manager  provides  many  vital  functions 
to  the  CSS  and  the  design  must  be  correspondingly  robust. 

It  is  conceivable  that  several  resources  may  desire 
access  to  data  maintained  in  the  CSS  which  implies  that  the 
generic  CSS  data  manager  be  capable  of  managing  a  distributed 
database.  Many  issues  related  to  data  security  and  control 
are  involved  in  designing  a  distributed  database,  see  Kroenke 
and  Dolan  (1988)  for  a  thorough  discussion. 
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3.   The  Revised  Model  Manager 

The  model  manager  is  to  perform  the  function  of  the 
schedule  generator  and  therefore  will  be  designed  to  manage 
schedules,  schedule  elements  and  their  related 
interdependencies .  The  four  basic  functions  then  become 
schedule  generation,  restructure,  update  and  report 
generation/inquiry . 

The  schedules  are  to  be  coded  in  the  same  fashion  as 
the  heuristics  coded  in  the  knowledge  acquisition  process  used 
in  expert  systems  development  (Hayes-Roth,  1983)  .  Experts  in 
the  fields  of  interest  are  interviewed  and  their  knowledge  is 
captured  as  a  set  of  heuristic  rules.  In  the  CSS  case,  these 
rules  would  reflect  the  best  way  to  coordinate  a  particular 
event.  Restructure  and  update  of  the  rules  must  be  possible 
to  accommodate  differences  between  the  ideal  "classroom" 
situation  and  the  often  less-than-ideal  "real-world" 
situation . 

Additionally,  the  model  manager  must  provide  for  the 
interface  with  the  dialogue,  data  and  communication  managers. 
Data  from  the  environmental  inputs  and  resources  must  be 
available  to  the  model  manager  so  that  it  may  monitor  the 
coordination  process. 

Schedules  for  AAW  might  include  one  for  intercepting 
hostile  aircraft,  one  for  downed  aircraft  search  and  rescue 
(SAR) ,  one  for  launching  and  maintaining  a  defensive  barrier, 
etc . 
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4 .   The  Revised  Communication  Manager 

a.  The  Group  Norm  Constructor 

The  group  norm  constructor  (GNC)  provides  the  means 
for  defining  the  coordination  elements  appropriate  to  each 
outcome.  Once  an  outcome  is  selected,  a  form  would  appear  on 
the  screen  with  blanks  to  fill  in  regarding  environmental 
inputs,  resources,  communication  channels,  and  time 
constraints.  Default  values  would  be  listed  where 
appropriate.  Once  all  inputs  were  provided  the  communication 
manager  would  send  the  data  to  the  schedule  generator  for 
compilation . 

b.  The   Group  Norm  Filter 

The  group  norm  filter  grants  access  to  the  CSS, 
enforces  the  protocol  defined  in  the  GNC  and  monitors  the 
schedule  generation  process.  This  means  that  all 
communications  take  place  only  between  the  elements  specified 
and  on  the  channels  defined  in  the  GNC. 

c.  Information  Formatter 

(1)  Environmental  Input  Data  Conversion.  The 
variety  of  possible  input  types  requires  that  a  module  be 
specified  for  the  purpose  of  converting  various  input  types 
into  data  streams  useable  by  the  model  manager  and  the  data 
manager.  Examples  include  analog  to  digital  conversion  and 
data  formatting.  This  module  will  vary  in  size  and  complexity 
with  the  domain  of  the  associated  CSS. 
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(2)    Resource     Monitor     Data      Conversion.  Since 

resources  also  communicate  directly  with  the  CSS,  data 
conversion  similar  to  that  explained  above  must  also  take 
place  for  both  inbound  and  outbound  data  streams.  Depending 
on  the  resource,  the  CSS  may  send  instructions  in  the  form  of 
text  or  digital  signals  for  example. 
d.    Invocation  Mechanism 

The  invocation  mechanism  is  designed  to  be  able  to 
modify  the  protocol  defined  in  the  GNC  after  the  coordination 
process  has  begun.  For  instance,  suppose  an  interceptor  loses 
its  ability  to  communicate  or  has  another  mission  critical 
failure,  the  invocation  mechanism  would  allow  the  user  to 
interrupt  the  coordination  process,  enter  information  on  a 
substitute  aircraft,  and  re-initiate  the  process.  In  a 
similar  fashion  communication  channels  and  environmental 
inputs  could  be  changed,  added  or  deleted. 
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VI.   SUMMARY  AND  REVIEW 

A.   SUMMARY 

In  developing  a  fresh  design  for  a  computer  system  it  is 
prudent  to  first  survey  existing  systems  that  have  common 
design  features.  This  study  examined  the  designs  of  DSS, 
GDSS,  OAS  and  EMS  technologies  to  determine  their  suitability 
as  a  foundation  for  developing  a  generic  CSS.  None  of  these 
designs  had  all  of  the  required  features  but  one,  the  GDSS, 
came  very  close. 

Next,  the  activity  of  coordination  was  studied  and 
decomposed  into  its  elements  of:  outcome,  environment, 
resources,  time,  schedule  and  communication.  It  was 
determined  that  each  element  must  be  built  into  the  CSS  at  the 
design  stage  before  proceeding. 

The  vital  role  played  by  communication  in  the  coordination 
process  was  discussed.  Noted  were  the  key  communication 
dimensions  spatial  distance,  temporal  distance,  centralization 
of  control  and  degree  of  cooperation.  A  time-space  taxonomy 
of  group  systems  was  provided  to  lend  perspective. 

A  great  many  factors  can  increase  the  complexity  of  the 
coordination  process.  Examples  were  provided  showing  it  is 
likely  that  as  the  environment  changes,  the  number  of 
resources  varies,  the  time  to  coordinate  events  decreases,  the 
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interdependence  of  events  increases  and  the  difficulty  of 
communication  increases,  events  become  much  more  difficult  to 
coordinate . 

Human  factors  such  as  subjectivity,  inability  to  parallel 
process,  slow  data  assimilation  and  irrationality  can  also 
affect  the  coordination  process. 

Some  advantages  of  a  CSS  were  described  such  as  faster 
information  processing,  parallel  processing,  resource 
management  capabilities,  automated  input  from  several  sources, 
and  quality  of  information  output. 

As  a  starting  point,  the  GDSS  architecture  proposed  by  Bui 
and  Jarke  was  used  to  describe  the  foundation  for  a  CSS.  Each 
component  of  the  dialogue  manager,  data  manager,  model  manager 
and  communication  manager  was  described  in  order  to  give  the 
reader  a  common  reference  point  when  discussing  the  design  of 
the  proposed  CSS. 

Before  outlining  the  structure  of  the  CSS  a  five  phase 
framework  was  developed  to  provide  a  system  description.  The 
phases  were  labelled  selection,  definition,  schedule 
generation,  output  and  monitor.  A  discussion  of  the  five 
phases  helped  the  reader  understand  the  function  and  scope  of 
a  CSS. 

Finally,  the  actual  modifications  to  the  GDSS  model 
required  to  design  a  generic  CSS  were  examined  component  by 
component.  Each  modification  was  proposed  to  better  support 
the  coordination  process  and  the  development  of  a  CSS. 
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B.   JUSTIFICATION 

To  undertake  the  actual  design  and  implementation  of  a  CSS 
would  require  an  investment  proportional  to  the  size  and  scope 
of  the  desired  system.  In  order  to  establish  the  utility  of 
a  CSS,  and  therefore  to  help  justify  the  investment,  it  is 
useful  to  analyze  system  requirements  with  respect  to  the  six 
elements  of  coordination.  The  answers  to  some  basic  questions 
will  help  to  begin  the  analysis: 


To  what  extent  are  the  outcomes  of  the  proposed  CSS 
recurring  requirements?  The  more  recurring  the 
requirement,  the  more  often  the  system  will  be  used. 

To  what  extent  can  environmental  inputs  provide  automated 
input  to  the  system?  The  greater  the  number  of  automated 
inputs,  the  less  data  acquisition  and  assimilation 
required  of  the  human  coordinator. 

To  what  extent  can  resources  be  controlled,  messaged 
and/or  provide  feedback  electronically?  The  closer  the 
control,  the  more  efficient  the  coordination. 

What  are  the  time  constraints  of  the  desired  coordination 
process?  The  shorter  the  allowable  time  to  complete  the 
coordination  process,  the  more  effective  the  system. 

To  what  extent  can  the  coordination  process  be 
premeditated,  i.e.,  is  there  a  "best"  way  to  sequence  the 
schedule  elements?  The  more  it  can  be  premeditated,  the 
greater  the  effectiveness  of  a  CSS. 

To  what  extent  can  communications  be  established  between 
environmental  inputs,  resources  and  the  CSS?  The  greater 
the  number  of  linkages,  the  greater  the  utility  of  the 
system. 


From  the  answers  to  these  questions  a  general  feel  for  the 
utility  of  a  proposed  CSS  can  be  sensed.  If  it  is 
subsequently  determined  that  the  proposed  system  is  worth  the 
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estimated  investment,  there  are  several  possible  benefits  of 
its  implementation.   Among  them  are: 


•  Faster  Coordination  of  Events  -  due  to  the  computational 
speed  of  the  computer,  the  rapidity  of  electronic 
communications  and  the  increased  rate  of  data 
assimilation . 

•  More  Efficient  Coordination  of  Events  -  due  to  the  reduced 
amount  of  time  and  effort  required  to  prepare  and 
coordinate  an  event  when  using  a  CSS. 

•  More  Effective  Coordination  of  Events  -  due  to  the 
incorporation  of  expert  knowledge,  the  schedule  generated 
for  execution  will  be  of  higher  quality  than  one  generated 
by  novices. 

•  Improved  Analysis  of  the  Coordination  Process  -  due  to  the 
ability  to  save  all  system  transactions  for  later 
retrieval  and  review. 

•  Improved  Allocation  of  Slack  and  Scarce  Resources  -  due  to 
the  automated  monitoring  of  resource  capabilities. 


These  are  only  a  few  of  the  more  obvious  benefits  of 
implementing  a  CSS,  others,  including  the  more  efficient  use 
of  resources  and  the  development  of  competitive  edge, 
certainly  exist.  Each  application  developed  would  most  likely 
have  a  unique  set  of  benefits. 

C.   ASSUMPTIONS 

Certain  assumptions  were  made  in  the  process  of  developing 
a  generic  CSS  design.  Among  them  that  there  is  a  best  way  to 
coordinate  an  event  and,  that  expert  knowledge  can  be  acquired 
and  reduced  to  code  for  implementation  in  a  CSS.  The  first 
assumption  implies  that,  given  a  set  of  selection  criteria,  an 
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expert  or  team  of  experts  could  select  from  a  set  of  possible 
sequences  of  schedule  elements,  the  sequence  that  is  least 
wasteful  of  time,  resources,  and  effort.  The  second 
assumption  is  supported  by  many  works  in  the  field  of  expert 
systems  and  has  been  the  guiding  principle  in  their 
development  (Davis,  1982) . 

D.   FURTHER  RESEARCH  QUESTIONS 

The  theoretical  design  of  any  system  is  only  the  very 
beginning  of  its  implementation.  This  thesis  was  intended  to 
be  the  very  beginning.  There  are  still  many  questions  about 
CSS  left  unanswered.   Some  include: 


•  Which  types  of  events  would  benefit  most  from  coordination 
using  a  CSS? 

•  What  is  the  best  way  to  manage  interdependencies  within 
the  schedule  generator? 

•  Could  a  coordination  system  that  learns  be  developed? 

•  To  what  extent  would  a  robust  CSS  alleviate  the  need  for 

training? 

•  What  contribution  to  the  development  of  CSS  will  come  from 
the  study  of  social  sciences? 


While  this  thesis  has  only  scratched  the  surface  of  the  many 
issues  surrounding  CSS  development,  it  has  provided  a  useful 
framework  within  which  to  perform  the  design  and  analysis  of 
coordination  systems.  Further  research  into  the  lower  level 
design  of  the  individual  modules  will  yield  great  benefits. 
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